THEMA: Artikel "Selectrix fahren"

Hallo Helmut,
Du hast recht, nur die Rautenhauszentrale und meine Selbstbauzentrale haben einen
separaten Programmiergleisabschluß.

Uwe

Hallo Uwe,

wie sieht Deine Selbstbauzentrale aus und wie ist sie aufgebaut? Gibt es darüber nähere Informationen?

Grüße, Peter W.

Das Fahrpult 844 ist mit einem seperaten Programmiergleisanschluss ausgestattet. Überhaupt ein feines Teil, mit dem man 4 Lokomotiven gleichzeitig steuern kann. Nur zu Empfehlen!!! Und überhaupt der Service - Spitzenklasse!!!
Bei www.MDVR.de oder aber auch bei Rautenhaus selbst!!!
Das muss malwieder gesagt werden!

Wolfi64

@2
siehe unter www.uwe-magnus.de

Uwe

http://www.1zu160.net/links/click.php?id=146

Wie sagte Hänschen Rosenthal immer: Das ist Spitze!!!

Gratuliere, das ist toll.

Hallo!

Sorry - das war eindeutig falsch und auch ganz eindeutig meine Schuld. Danke für den Hinweis und ich habe es jetzt schon geändert (+ Zusatz auf der Zentralen-Seite).

lg
ismael

@1/4

Hallo Uwe,

toll das wieder einer mehr mit Ahnung hier mitliest und schreibt.
Ich habe mal wieder auf deine Website geguckt und dort auch einen Ausblick auf SX2 gefunden, über das ja schon seit Jahren spekuliert wird.
Aber was da steht kann ich eigentlich gar nicht fassen. Es heisst dort dass eine SX2-Zentrale neben den normalen 112 Adressen (lassen wir mal beiseite ob die dann alle nutzbar sein werden) bis zu 64 Zusatzkanäle (=physikalische Adressen) bereitstellen wird.
Das macht also insgesamt bei optimistischster Betrachtung 112+64=176 nutzbare Lokadressen bei SX2, egal in welchem Zahlenraum die nun abgebildet werden. Wird das wirklich alles sein? Oder habe ich da einfach was falsch verstanden? Sonst müsste man wirklich wieder die Frage nach der Zukunftstauglichkeit von SX stellen.

grübelt
Helmut

@8
Hallo Helmut,
es ist nicht so, daß 64 "feste" Adressen dazukämen, sondern man kann in diesen 64  
Kanälen Loks mit 4 stelligen Adressen benutzen, also z.B. Loks mit der Adresse 1000 bis 1064 oder 2000 bis 2064 oder Loks mit den Adressen 1000, 3213, 4567 etc.
Die Lokdecoder können mit einer 4stelligen Adressen versehen werden, man kann bis
zu 64 von diesen Loks gleichzeitig benutzen, egal welche 4 stellige Adresse sie haben.

Uwe

@9
Hallo Uwe,

das ist doch genau das was ich geschrieben habe, 64 nutzbare physikalische Adressen, die wahlfrei in den Zahlenraum bis 9999 abgebildet werden.
Die Kernaussage ist also doch, es kommen nur maximal 64 Adressen dazu, egal wie sie nun benannt sind?
Dann wird also mit SX2 die Grenze der nutzbaren Lokadressen von (103 - Steuerwagen) erhöht auf (176 - Susi-Loks - Steuerwagen).
Das hätte mich leider kaum weitergebracht, wenn ich in der Hoffnung auf SX2 bei SX geblieben wäre.
Trotzdem viel Erfolg bei der Weiterentwicklung.
wünscht
Helmut

Hallo Digitalos,

Entschuldigung, wenn ich mich einmische, aber ich habe den Eindruck, dass man hier in der Diskussion über Sx2 etwas aneinander vorbei redet. Deshalb ein weiterer Versuch zur Erklärung der Sx2-Funktionalität.

In Verbindung mit Sx2 bleiben die bisher schon vorhanden 112 Adressen unangetastet und können ohne Einschränkungen weiter verwendet werden. Die Kompatibilität zum aktuellen Sx bleibt damit vollständig gewahrt. Was neu hinzukommt sind zusätzliche Frames zum Transport des Sx2-Protokolls, die dynamisch zwischen den Standard Sx-Frames eingebaut werden. Das bedeutet, es werden nur die Sx2-Frames gesendet, die zur Übertragung von Daten an die Adressaten gerade auch benötigt werden. Diese Sx2-Frames können frei genutzt werden, um jede beliebige Adresse aus einem Bereich von ca. 16.000 anzusprechen.

Eine andere Frage ist, wie viele von den 16.000 Adressen können gleichzeitig angesprochen werden? Oder in anderen Worten formuliert, wie viele Loks können im Sx2-Betrieb gleichzeitig fahren? Derzeit sind 64 vorgesehen. Das Protokoll erlaubt aber prinzipiell eine Erhöhung auf 128 oder gar 256. Wie gesagt zusätzlich zu den 100, die durch das aktuelle Sx-Protokoll schon versorgt werden können. Wenn meine Informationen stimmen, dann kann z.B. eine Intellibox max. 128 Adressen simultan aktivieren. Sicher können die Lenz- und Zimo-Experten die korrelierenden Zahlen ihrer zentralen nachreichen.

Die Limitierung auf dies in Relation zu den verfügbaren Adressen eher bescheidenen Anzahl ergibt sich aus der gewünschten Refresh Rate. Bei 128 aktiven Adressen beträgt diese bei NMRA-DCC bei Verwendung von langen Adressen und 128 Fahrstufen bereits ca. 2,3 Sekunden! Nur der Einsatz einer intelligenten Übertragung, die geänderte Werte bevorzugte überträgt ermöglicht es, den Verzögerungseffekt zu kaschieren. Bei zahlreichen Änderungen innerhalb kurzer Intervalle, wie sie im Computerbetrieb oder bei Clubs mit vielen Spielern durchaus vorkommen oder bei schlechtem Rad-Schiene-Kontakt stößt dieses Verfahren allerdings schnell an seine Grenzen.

Um zu verstehen, wie die genannten Herausforderungen bei Sx2 gemeistert werden sollen, hier eine Erläuterung zu den Sx2-Frames. Der Aufbau eines solchen Frames besteht aus 16Bit für die Decoder-Adresse, wovon nach meinen Informationen wahrscheinlich 2 Bit für besondere Anwendungen reserviert werden. Damit stehen effektiv "nur" 14Bit für die Adresse zur Verfügung. Dies erlaubt den Zugriff auf ca. 16.000 weitere Decoder-Adressen (BTW, so viele kann auch das neue mfx von Märklin).

Die Ähnlichkeiten zu mfx sind damit allerdings noch nicht am Ende. Auch bei Sx2 wird 1Byte für die Fahrtrichtung und die Fahrstufe verwendet. Dies ermöglicht die Anzahl der Fahrstufen von 31 auf 127 hoch zusetzen.

Letztendlich werden dann in dem Sx2-Frame noch 2Byte für Zusatzfunktionen transportiert. Dies ermöglicht den direkten Zugriff auf 16 Zusatzfunktionen. Auch dies ist identisch mit mfx. Wer jetzt mitgezählt hat, der wird festgestellt haben, das ein Sx2-Frame insgesamt 5Byte transportiert. Zusammen mit den Synchronisierbits (4 Stk.) und den Bits zum Check auf mögliche Übertragungsstörungen ergibt sich eine Frame-Länge von 64Bit (eventuell 68Bit falls man sich entscheidet 2 Sync-Zeichen zur Einleitung eines Sx2-Frames zu senden).

Die Übertragungsdauer eines solchen Frames liegt damit bei 3,2ms und ist somit um 50% kürzer als der aktuelle Sx-Frame. Dies ist insofern relevant, als die Wahrscheinlichkeit, dass ein Datenpaket gestört wird in erster Näherung linear mit der Länge des Datenpaketes ansteigt. Die störungsfreie Empfangswahrscheinlichkeit eines Sx2-Frames ist damit noch einmal deutlich höher als die der aktuellen Sx-Frames. Der Grund warum NMRA-DCC zwei separate Datenpaket sendet, um den gleichen Informationsgehalt zu übertragen, wie Sx2 in einem Frame liegt sicher auch darin begründet, dass ein solcher Frame dort eine zeitliche Länge von ca. 15ms aufweisen würde und zudem die sichere Erkennung von Übertragungsfehlern auf Grund der verwendeten Methode mit der Länge eines Datenpaketes abnimmt. Nachteilig wirkt sich bei der Aufteilung allerdings der erhöhte Overhead (Preamble, CRC-Check) aus, der letztendlich zu einer Gesamtübertragungsdauer von ca. 18ms führt.

Damit nicht der Eindruck entsteht Sx2 wäre gleich mfx, hier noch ein Auszug aus dem aktuellen Werbeprospekt von ESU zu mfx:

*** Zitat-Anfang
Wie eingangs erwähnt, benötigt man für große Anlagen eine möglichst hohe Bandbreite. Dies wird bei mfx durch dynamische Paketlängen und intelligente Datenkompression erreicht. Ein typisches mfx-Paket zur Übertragung der Fahrstufe, der Fahrtrichtung und des Zustands aller Funktionen benötigt durch all diese Maßnahmen zur Übertragung etwa 5,3 ms - im Gegensatz etwa zu einem DCC-System, das die nötigen Pakete erst nach gut 29,4 ms gesendet hätte. Generell überträgt mfx seine Pakete etwa 3 - 7 mal schneller als DCC.
*** Zitat-Ende

Noch einmal der Hinweis bei Sx2 ist die Frame-Dauer 3,2ms. Damit ergibt sich bei 64 aktivierten Frames eine Refresh Rate von 64*3,2ms = 204,8ms. Dabei ist allerdings außer acht gelassen, das auch noch die 16 Standard Sx-Frames übertagen werden müssen und damit kommen noch einmal 76,8ms dazu. Dies führt zu einer Gesamtzeit von 281.6ms. Da die Empfangswahrscheinlichkeit wie der Sx2-Frames höher ist als die der Standard Sx-Frames (siehe oben) hat man sich entschieden die Sx2-Frames nur halb so oft zu übertragen wie die normalen Sx-Frames. Dies führt zu einer Refresh Rate der Standard Sx-Frames von ca. 180ms und bei den Sx2-Frames zu ca. 360ms.

Es ist nicht auszuschließen, dass insbesondere bei den Sx2-Frames nunmehr Verzögerungen in der Übertragung durch den Menschen wahrgenommen werden können. Sollte dies der Fall sein, so lässt sich dieses Problem natürlich leicht dadurch lösen, indem man geänderte Daten wie bei NMRA-DCC bevorzugt überträgt. Diese Performance steigernde Möglichkeit besteht selbstverständlich sowohl für die aktuellen Sx-Frames als auch für die neuen Sx2-Frames. Lassen wir uns überraschen was Sx2 bringen wird und zu welchen Aktivitäten sich die Programmierer hinreisen lassen. Hallo Uwe .

> Bei 128 aktiven Adressen beträgt diese bei NMRA-DCC bei Verwendung von langen Adressen und 128 Fahrstufen bereits ca. 2,3 Sekunden!

ein DCC-Datenpaket ist nach meiner Quelle 5ms lang, nach deiner 18ms, interessanter Unterschied. Was am Gleis los sein muss, damit 128 Änderungen im Zeitraum von 1-3 Sekunden anfallen, mag man auch überlegen. Es wird wohl kein Fahrzeug mehr als 1-2 Änderungen pro Sekunde überhaupt umsetzen können.

> Dies führt zu einer Refresh Rate der Standard Sx-Frames von ca. 180ms und bei den Sx2-Frames zu ca. 360ms.

und zwar egal, ob man eine oder 100 Loks hat, für die sich Änderungen ergeben. ...Realtime.
In der Zeit dürfen bei DCC nach deiner Rechnung 20, nach meiner 72 Änderungen anfallen, bis SX2 schneller ist.

Stellen sich 3 Fragen:
1. wieso kommt jeder auf für sich günstigere Zeiten?
2. wieso werden bei DCC mehr Daten übertragen? Evtl. mehr Informationen?
3. sind 0,36s *feste* Reaktionszeit besser oder je nach Last irgendwas ab 0,005s?

Guten Morgen Herr Lahmann,
besitzen sie überhaupt eines der von Ihnen angesprochenen Digitalsysteme?

Ist manchmal zu bezweifeln.

Mit freundlichen Grüßen
die Lokdecoder

Hallo Digitale Glaubenskrieger

@W. H.
Richtig verstanden heißt das : Sx´ler haben dann ca. 16.000 Adressen zur Verfügung und diese werden intern auf die 112 Adressen verteilt?!?

Wäre doch ein Vergleich interessant zwischen SX und DCC.
Ob DCC es überhaupt schafft Fahr/Schaltbefehle in der selben Geschwindigkeit (wie SX) an 112 Adressen gleichzeitig weiterzugeben. Ist wohl zu bezweifeln.
Systemzusammenbruch!

Abgesehen davon. Eine Anlage mit 112 gleichzeitig laufenden oder Befehle empfangenen Lokomotiven/Decodern kann ich mir wirklich nicht vorstellen.
Ist wohl nur Computerbahnern vorbehalten.

Verbleibe mit nachdenklichen Grüßen,
Modellbahner Markus

Hallo!

Wenn ich es richtig verstanden habe, dann:
112 Systemadressen immer, wie auch schon bisher.
Zusätzlich 64 gleichzeitig aktive Adressen aus dem Adressraum 113 bis ~16.000. Wobei diese 64 Adressen dynamisch angesprochen werden können - soll heißen, wenn du 100 Loks aus dem erweiterten Adressraum auf der Anlage stehen hast, dann können eben nur 64 gleichzeitig angesprochen werden. Wird eine Lok nicht mehr angesprochen, so kann eine andere Lok dafür angesprochen werden.

lg
ismael

danke, hast recht.
Stelle mir als Sx´ler- Modellbahner aber doch die Frage: Wer braucht sowas, ausser Betriebsnummern-Fetischisten?

Gruß
Markus

Alle Polemik beiseite schiebend - als Techniker interessiert mich wirklich die Frage, warum unterschiedliche Leute zu unterschiedlichen Zeitannahmen bei DCC kommen.
Kann das bitte wer sachlich erläutern?

Danke

Enrico

Hallo!

Das Problem bei der Zeitannahme bei DCC ist zumindest zweiteilig:

- es kann aus mehreren, aber mindestens aus 3 Bytes bestehen
- eine 0 zu Übertragen dauert länger als eine 1 zu übertragen, da nicht die Polarität der Flanken ausgewertet wird, sondern die zeitliche Abfolge. Eine 1 dauert 116 Mikrosekunden, eine 0 mind. doppelt so lang.

Daher dauert eine Info unterschiedlich lang, je nachdem wie viele 1 und 0 dabei sind und dann noch eben, aus wie vielen Bytes die Info besteht. Ich habe mir das druchgerechnet und kam da so auf Zeiten zwischen 3 und 8 ms - von daher ist die Angabe (wer auch immer die mal in die Welt gesetzt hat - aber man liest sie immer wieder) mit einer durchschnittlichen Zeit von etwas mehr als 5 ms für eine einfache Lokinfo (kurze Adresse, 14 FS) durchaus realistisch. Im Betrieb mit langen Adressen und höherer Fahrstufenanzahl aber etwas länger.

(PS: Ich bin gerade am Schreiben einer Artikelserie über DCC wie sie jetzt über Sx erscheint und dort werden die Angaben auch zu finden sein - das wird aber wohl erst im nächsten Jahr fertig sein, da dafür doch einiges an Recherche etc. notwendig ist und das braucht seine Zeit. An dieser Stelle auch schon mal danke an die Leute, die mir vorab schon bei der Korrektur und Erstellung immer wieder helfen, wenn ich eine Frage habe.)

@16: Einen Vorteil haben die langen Adressen auf jeden Fall: ein ÖBBler kann eine 1044 unter 1044 ansprechen, eine DB 152 als 152. Das ganze relativiert sich aber derzeit, da die meisten SX-Regler auch vorgeschobene Alias-Namen unterstützen und in einer internen Datenbank abspeichern.

lg
ismael

Ich hab jetzt einmal die NEM 670 und 671 intensiver durchgelesen und festgestellt, dass das längste Datenpaket für das Dekoderrücksetzen ist - das dauert normgemäß 7.140µs, also knapp 7,2 ms. Ein normales Fahrstufen-Datenpaket dauert etwa 5,18 ms.

Um also 128 Dekoder mit unterschiedlichen Fahrstufenbefehlen anzusteuern, benötigt man also 128 x 5,2 ms + 127 Pausen x 5 ms = 1,3 sec. Da sind allerdings keine Wiederholungen eingerechnet.

Kann mir nun bitte @11 W.H. erklären, wie er auf die DCC-Zeiten kommt? Habe ich einen Gedankenfehler gemacht?

Danke

Enrico

Hallo!

@ 11 schreibt:

####
Bei 128 aktiven Adressen beträgt diese bei NMRA-DCC bei Verwendung von langen Adressen und 128 Fahrstufen bereits ca. 2,3 Sekunden!
####

Wie schon unter 18 geschrieben, macht es einen Unterschied, wenn ich lange Adersse und mehr Fahrstufen anspreche. Inwieweit die 2,3 Sekunden stimmen, kann ich nicht sagen, da ich es mir noch nicht durchgerechnet habe.

lg
ismael

Hi Ismael!

* wenn mehrere Fahrstufen angesprochen werden
- dann muss auch SX ein Telegramm je Fahrstufe senden

* lange Adressen
- verlängern das Datenpaket um 8 bit (im Extremfall 116µs x 8 = 0,92 ms) auf etwa 6,1 ms

Ich komm dann immer noch nicht auf 2,3 Sekunden. Und als Techniker stört es mich, wenn irgendwer etwas behauptet, dass sich so nicht belegen läßt.

Mir gefällt sowohl SX als auch DCC und ich bin für eine sachliche Diskussion der Vor- und Nachteile der Systeme - solange das nachvollziehbar ist, habe ich keine Probleme. Ich denke, SX/SX2 hat es nicht notwendig, dass mit - sagen wir nicht nachvollziehbaren - Angaben gearbeitet wird.

Enrico

@16
>Stelle mir als Sx´ler- Modellbahner aber doch die Frage: Wer braucht sowas,
>ausser Betriebsnummern-Fetischisten?
Jemand mit grossen Schattenbahnhöfen und einem großen Bw

@14
>Abgesehen davon. Eine Anlage mit 112 gleichzeitig laufenden oder Befehle
>empfangenen Lokomotiven/Decodern kann ich mir wirklich nicht vorstellen.
>Ist wohl nur Computerbahnern vorbehalten.
Jeder Digitalbahner der einen einigermassen realistischen Fahrbetrieb nachbilden will, wird zwangsweise zum Computerbahner, da es mW derzeit keine andere Möglichkeit gibt eine realistische Steuerung über Blöcke und Fahrstrassen zu realisieren als über Computersoftware.

@21
Mir liegt durchaus auch an einer sachlichen Diskussion anstelle von Polemik. Um Vor- und Nachteile gings mir aber bei diesem Thread eigentlich gar nicht sondern ursprünglich nur um die Korrektur des Fehlers mit dem Programmiergleis. Und dann bin ich einfach neugierig geworden, nachdem ein bekannter SX-Insider geantwortet hat.

schönen Abend noch
Helmut

Ein erneutes Hallo an alle Digitalos,

da man mich ja darum gebeten hat, wie ich auf die von mir für NMRA-DCC angegebenen Zeiten komme, nachfolgend einige Erläuterungen dazu. Obwohl wir in diesem Thread eigentlich über Sx und vielleicht auch ein wenig über Sx2 diskutieren wollten .

Wie an anderer Stelle in diesem Thread bereits gesagt verwendet NMRA-DCC die FSK-Methode (Frequency Shift Keying) zur Bit-Codierung. Dabei besteht jedes Bit aus einem positiven und einem negativen Impuls gleicher Länge. (Wenn man einmal von den stretched zero bits zur Ansteuerung nicht auf Digitalbetrieb umgerüsteter Loks absieht. Dies würde zudem das Faktum der hier diskutierten Übertragungszeiten dramatisch verschlechtern.)

Eine log. "1" ist laut Norm durch einen positiven und einen negativen Spannungsimpuls von je 58us definiert und dauert damit 116us. Eine log. "0" besteht laut Norm aus einem positiven und einem negativen Spannungsimpuls von min. je 100us, wobei hier im allgemeinen Impulszeiten von ca. 110us üblich sind. Die Übertragung einer log. "0" dauert damit 220us.

Die nächste Frage, die sich stellt lautet nun, wieviele Bits werden den in einem NMRA-DCC Telegramm übertragen? Schauen wir uns hierzu zunächst einmal den ursprünglichen, auch heute noch gültigen Aufbau, eines Datenpakets an. Ein Datenpaket wird bei NMRA-DCC eingeleite durch eine sogenannte Preamble. Diese Sequenz dient zur Synchronisierung und besteht aus mindestens 14 log. "1" Bits und einer abschließenden log. "0". Die Übertragung der Preamble dauert damit mindestens 1,83ms.

Warum sage ich mindestens. Nun die Norm (z.B. NEM671) spricht hier von mindestens 10 log. "1" Bits, die ein Empfänger erhalten muss, um zu synchronisieren und fordert gleichzeitig, dass ein Sender (die Zentrale) dazu mindestens 14 log. "1" Bits zur Synchronisation sendet. Einige Zentralen senden allerdings noch deutlich mehr log. "1" Bits und dies ist auch gut so.

Im Rahmen der avisierten bidirektionalen Kommunikation ist vorgesehen, das einige der Preamble Bits herausgeschnitten werden, um dem Lokdecoder Gelegenheit zu geben, in dieser Signalpause Daten in Richtung Zentrale zurückzuschreiben. Allerdings müssen zur Sicherstellung der Synchronisation immer noch 14 log. "1" Bits übrig bleiben. Welches Zeitfenster hat den diese (neue) Cutout Time? Laut RP-9.3.1 V1.0 vom April 2003 beträgt diese Zeit min. 448us. Sie entspricht damit quasi der Übertragungsdauer von 4 log. "1" Bits und so ist es auch nicht verwunderlich, dass zukünftig mindestens 18 Preamble Bits laut Norm gefordert werden. Dies erfüllen diverse Zentralen allerdings schon heute, da sie schon immer mit 20 log "1" Preamble Bits arbeiteten.

Abschließend kann man also zur Übertragungsdauer der Preamble sagen, dass sie mindestens 1,83ms dauert und zukünftig, wegen dem Feature der bidirektionalen Kommunikation, aber min. 2,3ms betragen sollte.

Hier ein kleiner Ausflug zu Sx und Sx2. Die Synchronisationssequenz besteht bei Sx aus 4 Bit und dauert konstant 0,2ms. Bei Sx2 ist es nach meinem Kenntnisstand noch offen, ob man ein Sx2-Datenpaket mit einer oder 2 Synchronisationssequenzen einleitet. Beides wäre möglich. Demnach dauert die Synchronisation bei Sx2 entweder auch 0,2ms wie bei Sx oder eben 0,4ms.

Wie ist es hier aber mit der bidirektionalen Kommunikation. Nun hier stellt sich nach meiner Auffassung ein weiter Vorteil der Sx-Signalcodierung dar. Sx und das im Codierverfahren identische Sx2 verwenden eine synchrone Datenübertragung. Dies bedeutet, das Taktsignal wird mit übertragen. Am Gleis wird dies dadurch erreicht, dass jedes Bit aus einem Impuls von 40us und einer Pause von 10us besteht. In diesen natürlichen Pausen zwischen den einzelnen Bits kann der Sx-Decoder Daten in Richtung Zentrale zurückschreiben. Davon wird heute schon im Zusammenspiel mit den aktuellen Lokdecodern und dem Besetztmelder BM8i von MUET Gebrauch gemacht. Bei Sx2 werden dem Lokdecoder durch die natürlichen Taktpausen im Sx-Signal ca. 600us zur Verfügung stehen, während der er Daten in Richtung Zentrale senden kann.

Sorry für den erneuten Ausflug nach Sx, schnell zurück zu NMRA-DCC. Was hatte ich gerade gesagt, ach ja, dass die Übertragung der Preamble eines Datenpakets ca. 2ms in Anspruch nimmt. Jetzt fehlen allerdings noch die eigentlichen Daten und der CRC-Check.

Hier zunächst wieder zurück zu dem ursprünglichen und auch heute noch gültigen Datentelegramm. Dieses überträgt nach der Preamble 2 weitere, durch log. "0" Stopbits getrennte Datenbytes und ein abschließendes CRC-Byte gefolgt von einer log "1" als Packet End Bit. In Summe kommen also hier noch einmal 27Bit hinzu. Nimmt man vereinfacht eine Gleichverteilung der zeitlich unterschiedlich langen "0" und "1"-Bits an, so kommt man auf eine Übertragungsdauer von ca. 4,5ms. Zusammen mit der unabdingbar notwendigen Preamble ergibt sich also eine Gesamtübertragungsdauer für dieses Datenpaket von ca. 6,5ms.

Na ja wird der ein oder andere sagen, worüber streiten wir den, ob es nun 5ms oder 6,5ms sind ist doch egal. Nun für mich beträgt die Differenz in den Angaben 30%, aber ich möchte mal nicht so dogmatisch sein allerdings ist die Geschichte hiermit noch nicht zu Ende.

Hier wird von vielen gepriesen, dass NMRA-DCC über 10.000 Lokadressen ansprechen kann und über 128 Fahrstufen verfügt und zudem 12 Zusatzfunktionen bedienen kann. Stimmt! Allerdings nicht mit dem gerade beschriebenen Datenpaket. Um lange Adressen mit 128 Fahrstufen anzusprechen, muss ein Datenpaket gesendet werden, welches nach der Preamble 5 weitere, jeweils durch eine log. "0" getrennte Datenbytes enthält und wiederum durch eine log. "1" als Packet End Bit abgeschlossen wird. Es werden in diesem Fall also 45 weitere Bit nach der Preamble gesendet. Bei einer gemittelten Übertragungsdauer eines Bits von ca. 165us ergibt sich hiermit zusammen mit der Preamble eine Gesamtdauer von ca. 9,5ms.

Wer jetzt angenommen hat, dass darin schon die Informationen für die 12 möglichen Zusatzfunktionen enthalten sei, den muss ich enttäuschen hierfür wird ein weiteres Datenpaket an den selben Adressaten benötigt. Diese besteht aus der Preamble, 4 weiteren Datenbytes und den erforderlichen 4 Stopbits. Macht in diesem Fall 36 weitere Bits nach der Preamble. Die mittlere Übertragungsdauer ergibt sich damit zu ca. 6ms und unter Addition der notwendigen Preamblez-Zeit kommen wir hier auf ca. 8ms.

Quintessenz ist also, dass ein NMRA-DCC System knapp 18ms benötigt um eine Lok mit langer Adresse und 12 Zusatzfunktionen anzusprechen (warum ESU hier allerdings knapp 30ms ins Feld führt ist mir unbekannt). Wie bereits in meiner Ursprungsnachricht gesagt wird Sx2 hierfür 3,2ms benötigen wobei hier sogar 16 Zusatzfunktionen an der Stelle von 12 angesprochen werden.

Ich kenn die Aussage vieler NMRA-DCC Anhänger, dass die Refresh Rate der Datenpaket und deren Länge keine Rolle spielt, sondern es nur darauf ankommt wie schnell das Datenpaket bei der Lok ankommt. Hierzu empfehle ich, vielleicht doch noch einmal einen Blick in die Nachricht #11 zu werfen. Es ist völlig unstrittig, dass auch ein NMRA-DCC System funktioniert. Sein Bit-Codierungsschema, sein Protokoll und die wenig überzeugende Hamming-Distanz von 2 seines CRC-Checks ringen mir allerdings keinen großen Respekt ab.

Zudem ist die Angabe, dass in Verbindung mit modernen NMRA-DCC Zentralen ein Datenpaket innerhalb von 5ms beim Adressaten sei, nicht nur wegen der Datenpaketlänge falsch, sondern auch wegen der nicht umfassenden Betrachtung der Latenzzeit. Dies ergibt sich aus der Übertragungszeit vom Eingabegerät (oder haben alle hier nur Zentralen mit integriertem Fahrregler) zur Zentralen und der daran anschließenden Zeit, die die Zentrale benötigt um das Datenpaket zum Empfänger zu senden. Wie schnell die Eingabebusse der verschieden Zentralen tatsächlich sind wäre ein anderes Diskussionsthema. Bei den immer wieder ins Feld geführten, von der Systemauslastung unabhängigen 80ms bei Sx ist diese Zeit allerdings von den "Kolporteuren" stillschweigend oder auch unwissend mit eingerechnet.

Es ist zwar richtig, dass Sx derzeit alle Datenpaket in einem festen Muster zyklisch überträgt, es ist aber nicht richtig, dass im Sx-Protokoll neben dem zyklischen Datenverkehr kein spontaner, azyklischer Transfer möglich sei. Wegen der schnellen Datenübertragung kann sich Sx derzeit die konstante zyklische Übertragung aller Datenpaket erlauben, da die menschliche Sensorik Zeiten von 80ms nicht auflösen kann. Die Option geänderte Datenpaket prioritätsbehaftet zusätzlich azyklisch, wie bei NMRA-DCC üblich und auch notwendig, zu übertragen, steht selbstredend auch bei Sx zur Verfügung.

Ich hoffe, man sieht mir meinen erneuten Ausflug in die Sx-Welt nach. Er soll keinesfalls dazu dienen Anhänger des NMRA-DCC Systems zu missionieren. Wie sagte schon König Friedrich der Große (der alte Fritz) "Die Religionen müssen alle toleriert werden, und muss der Staat ein Auge darauf haben, dass keine der anderen Abbruch tue, denn hier muss jeder nach seiner Fasson selig werden können."

In diesem Sinne wünsch ich allen noch einen schönen Abend.

vielen Dank für die umfangreiche Information
Klaus

Hallo!

Wieder mal die alte Leier.

Aber allen vorraus Enrico, Kai  und alle die auf  5-6ms bei DCC gerechnet haben, haben recht.
Erklärung wie folgt:

Die reine Geschwindigkeitsänderung (ohne sonst was, allerdings als vollständiges Signal) sollte sich also folgendermaßen berechnen lassen:

"1" Bit Duration
Period A >=52µSek <=64µSek
Period A = Period B (pos Flanke + neg Flanke) Bit Duration =Durchschittlich
120µSek
"0" Bit Duration 200µs typ.

Decoder muß empfangen:

12 Präambel Bits             "1"                      1440µs
1 Start Bit                        "0"                       200µs
8 Adress Bits (16 bei langen Adressen) zB 00110011  4*120µs+4*200µs=1280µs
(2560µs bei 16 Bit) max.4000µs
1 Data Start Bit                "0"                       200µs
8 Data Bits                       "0"/"1"          zB 01001011 1280µs
(max.2000µs)
1Data Start Bit                    "0"                    200µs
8 Error Correction Bits     "0"/"1"          zB   10110100 1280µs (max.
2000µs)
1 Packet End Bit                "1"                    120µs
---------------------------------------------------------------------------------------------
Summe 40 Bits   mit typ.                        6000µs = 6 ms
bzw. 7280µs bei langer Adresse
                            max .                    10160µs   =10,2ms
                            min.                           5280µs= 5,3ms






Quintessenz ist also, dass ein NMRA-DCC System knapp 18ms benötigt um eine Lok mit langer Adresse und 12 Zusatzfunktionen anzusprechen (warum ESU hier allerdings knapp 30ms ins Feld führt ist mir unbekannt)............

Dazu die NMRA Norm:
It shall be possible to configure Digital Command Stations to transmit at
least one complete packet every 30 milliseconds as measured from the time
between packet start bits 12.13
12 Some DCC decoders manufactured prior to the NMRA standards require a
valid baseline packet be received every 30 milliseconds to prevent analog
power conversion.
13 Longer repetition rates may result in less than optimal decoder
performance

Anm: DCC kanns wenigstens, bei SX ist ja keine Rede davon



Woher die 116ms kommen ist mir schleierhaft, da die NMRA nur sagt:
In a "0" bit, the duration of the first and last parts of each transition shall nominally be greater than or equal to 100 microseconds.......A Digital Decoder must accept
bits whose first or last parts have a duration of between 90 and 10000 microseconds as a valid bit with the value of "0".

http://www.dcc.info/standards_rps/S-91-2004-07.pdf

Ich habs mal bei d.r.m.b. mal vorgerechnet.
Breake even DCC/SX ist (bei einer guten Zentrale) bei 15 GLEICHZEITIG abgesetzten Befehlen. Ab dann wird SX rechnerisch schneller. Bei Software, die sowieso nur sequentiell arbeitet, Handregelbetrieb ect kommt das typ. DCC Steuersignal aber statistisch schneller zum Decoder als bei SX.

LG, Herkules

Korrektur:
"Woher die 116ms kommen ist mir schleierhaft, da die NMRA nur sagt:"
Sorry natürlich die 210ms, da ja ein "0" Bit fast beliebig lang sein kann aber auch nur >180µS Dauer haben muß.


Allerdings sagt die Norm zum "One-Bit"

For Power Station Output under Load:
Relationship for One Bits Result
Period A < 55 µSec or Period A > 61 µSec Bad
Period A = Period B OK
|Period A – Period B| <= 3 µSec OK
|Period A – Period B| > 3 µSec Bad
Decoders must accept:
Relationship for One Bits Result
Period A >= 52µSec and Period A <= 64 µSec OK
Period A = Period B OK
|Period A – Period B| <= 6 µSec OK:

Das "1" Bit könnte also auch zwischen 107 und 125 µS dauern. (nur für wirklich Interessierte

LG,Herkules

Und jetzt? Etwas anderes als du hat W.H ja auch nicht herausbekommen.
H.W.: Adresse + Geschwindigkeit: 6,5 - 9,5 µs, du 5,3 - 10,2 µs. Und für die Funktionen gibt es halt noch 8 µs drauf.

Wozu also die ganze Aufregung. Ich finde H.W. hat die Vor- bzw. Nachteile SX vs. DCC geschildert und auch die "Fussangeln" von SX nicht verschwiegen.

Zastrow
auch DCC

Leute merkt Ihr überhaupt noch, in welchen Diemnsionen ihr euch bewegt?

MIKROSEKUNDEN!!!!!! 1 µs = 0,000001 s

Da ist wohl die Praxisrelevanz unabhängig von DCC oder Sx etwas abhanden gekommen, oder?
Also - meine Loks kümmert das relativ wenig, wenn die da eine tausendstel Sekunde später losfahren oder nicht, sie fahren trotzdem.

Gruß Stefan

@W.H. wer immer du bist.

Prinzipiell stimmen deine Angaben soweit. Es ist aber auch so, daß jeder, der DCC nicht "genau" ansieht, hier Denkfehler produziert (wie auch ich am Anfang .

DCC ist ein altes Protokoll und daher leider nicht mehr so einfach anpassbar als wenn man gleich etwas neues stricken würde (zB mfx).
Zu der RP 9.3.1 ist leider zu sagen, dass hier erstmals kontraproduktive Kräfte innerhalb der DCC-WG tätig sind. Nicht jeder wünscht sich Bi-Di so, wie es in der RP vorgesehen ist. Allerdings muß auch gesagt sein, daß die Bi-Di in DCC wesentlich umfangreicher ist als mfx heute oder SX2 irgendwann. Und natürlich lassen sich Daten nicht beliebig komprimieren oder substituieren. Auch die Methodik der Bi-Di Übermittlung ist fragwürdig und würde bei einer Neukonstruktion eines Datenformates niemanden so einfallen.

Selectrix ist aus meiner heutigen Sicht ein ideales Format zum schalten (dank Hr. Radtke von Rautenhaus habe ich diese Einsicht gewonnen
Fahren würde ich mit DCC oder mfx.

Warum: Die starre Struktur von SX ist ideal um Abläufe zu automatisieren. 896 "Adressen" / Bus sind sicher genug und bei Bedarf mit einem 2. Bus zu verdoppeln.
Allerdings sieht man dabei eben schon die Schwäche, die vermeindlich keine ist. Denn das sind eben nur 8x112 Kanäle. Wer jetzt nachrechnet, weiß, daß er dabei genau einen Decoder mit Motorausgang, Licht*2 und max. 2 Funktionsausgänge dafür bekommt. Und nicht mehr.
Jeder halbwegs gute DCC Decoder hat da mehr zu bieten. Und das kostet. Und zwar Daten. Lokadressen sind nur vorgeschoben, um hier Funktionalität zu erreichen. Wie wir alle wissen, braucht niemand 16.000 Adressen, wenn sich seine 20 (oder von mir aus auch 200) Loks mit dem richtigen Namen anmelden. Und natürlich braucht auch keiner 128 externe Fahrstufen, wenn der Chip sie automatisch berechnet.
Wenn ich anfahren will, sei es mit Computer oder manuell, sage ich dem Decoder (mit einem Befehl) fahre auf Strecke x auf Fahrstufe y - alles andere macht der Prozessor. Und mit Bi-Di brauche ich nichtmal mehr sagen "fahre im Bahnhofsbereich langsam", denn auch das erkennt er dann.....

Jaja, jetzt kommt FREMO und sagt:"alle meine Mitglieder verschieben ja ununterbrochen" und "bei der Menge an Befehlen kommt es immer zu Verzögerungen". Und JA, es stimmt - weil sie unintelligente Zentralen verwenden. Das wird auch nicht mit Bi-Di besser, sondern nur, wenn man sich eine bessere Zentrale zulegt, die Eigenintelligenz besitzt. Aber selbst wenn 100 FREMOianer gleichzeitig (innerhalb von 0,3 Sek) DCC-Fahrbefehle aussenden, kommt es dabei nur zu einer Verzögerung (beim letzten Teilnehmer) von 0,3 Sekunden. (Bitte Nachrechnen ))

Und da kommen wir zu Pudels Kern: Was nützt uns mfx, DCC-Bi-Di oder SX2. Nichts, wenn wir nur 2 Loks fahren lassen, nichts, wenn die Lok sowieso nur Lichtwechsel hat, nichts, wenn wir nur 2 Weichen in einem Ausweichgleis haben.

All diese Features der "Superprotokolle" werden dann relevant, wenn es komplexer wird. Und "komplexer" bedeutet > 50 gleichzeitig fahrende Loks, > 100 Weichen (zB in einem Ablaufberg oder einer Fahrstraßensteuerung) > 200 Magnetartikel oder Rückmelder.
Jetzt frage sich jeder selber, ob er überhaupt in diese Gruppe fällt. Danach sollte er sich Gedanken machen, ob sein verwendetes System seinen Ansprüchen gerecht wird. Oder ob er mit Verzögerungen im Bereich von Zehntelsekunden leben kann.

Mit digitalen Grüßen, Herkules

@Zastrow

Natürlich kommen wir rechnerisch auf "dasselbe" Ergebnis. Jeder kann die RP lesen und nachrechnen - ist ja keine Hexerei.
Warum du aber auf 8ms für Funktionen kommst ist mir nicht ganz klar. Ein Fahrbefehl hat das selbe Format wie eine Funktion, dauert also auch genausolange
Das ist eben der Denkfehler, das man glaubt, alles wird sofort in einem Paket übermittelt und dann ist Schluß. Es kann so sein, muß aber nicht.
Wenn zB ein Zug fährt und würde mittels Bi-Di vor dem Tunnel das Licht einschalten wird trotzdem nur ein Paket mit der Länge von durchschnittlich 8ms (oder ca. 9-9,5 bei langer Adresse) gesendet - und keine Geschwindigkeitsinfo. Und in den Tunnel passt nur ein Zug (pro Seite vielleicht - wenn zweispurig).

Also wiedermal ein Denkfehler. Ist aber kein Problem solange er erkannt wird.

LG, Herkules

Von Bi-Di ist überhaupt nicht die Rede, das wird sowieso ein Griff in den A...., solange nicht komplett neue Übertragungsverfahren samt Protokollen implementiert werden. Um beim Beispiel zu bleiben:
Wenn ich vor dem Tunnel die Geschwindigkeit verlangsame und das Licht einschalte werden die 2 Datenpakete gesendet, egal ob sequentiell oder mit anderen Datenpaketen zeitlich gemultiplext, die benötigte Zeit bleibt die gleiche. (ohne dass ich jetzt um bits feilsche). Etwas gänzliche anderes ist die Reaktionszeit des Systems analog Elektronengeschwindigkeit <>Fortpflanzungsgeschwindigkeit. Und um dieses zu dokumentieren, reicht die ganze Herumrechnerei hier nicht.

Zastrow

Ok, wenn ich diesen ganzen Technobabbel richtig verstanden habe, ist es also für Otto Normalbahner mit seiner kleinen Bahn, die für 5 Züge ausgelegt ist, schnurzpiepegal, ob er DCC odr SX fährt.

Es ist nur eine Frage, ob die Farbe der Zentrale zu Tapete passt, oder?

Da hätte man sich einige Grobheiten hier ersparen können.

lg,
Claus

Hallo Claus!

Genau so ist es! Es ist schnurzpiepegal. Es sind nur Animositäten mit dem einen oder anderen System. Es ist sogar egal wenn du 20 Züge fährst.

Es wird "nur" bei H0ern oder größer interessant, da man hier mehr Funktionen aus einem Decoder "braucht". Aber bei H0 gibt es sowieso kein SX. Und echte "Grobheiten" sind ja keine verteilt worden

Apropos Claus: Habt ihr Santa oder das Christkind auf Saipan?

LG, Herkules

Hallo Digitalos,

sorry, wenn ich mich noch einmal melde, ich wollte mit meiner "alten Leier" (siehe #25) hier keinen langweilen. Ich bitte höflichst dies zu entschuldigen. Eventuell basiert dieser Sachverhalt aber auch auf dem Umstand, dass das große Sternbild Herkules am nördlichen Sternhimmel zwischen Leier (Lyra) und Corona Borealis angesiedelt ist.

@29 beginnt mit:
> @W.H. wer immer du bist.

Dies ist sicher ohne jegliche Provokation als ein charmanter Hinweis zu verstehen, mich hier näher vorzustellen. Dieser Einladung komme ich gerne nach. Ich muss allerdings vorausschicken, dass ich keine so herausragenden Leistungen vollbracht habe, wie z.B. Atlas zumindest temporär von seiner Aufgabe zu entbinden und für ihn die Welt zu tragen und zugegeben auf meinen Schultern lastet auch nicht die Bürde von NMRA-DCC.

Deshalb möchte ich hier keinen mit meiner belanglosen Vita langweilen. Nur soviel: Ich bin ein langjähriger, zufriedener SelecTRIX User, der sich extrem nach Sx2 sehnt und es benötigt, über einen gewissen automatisierungstechnischen Background verfügt und damit auch mit den Methoden und Algorithmen der Fuzzy Logic vertraut ist.

Dies ist ein weiterer Grund warum ich mich noch einmal in diesem Thread zu Wort melde, obwohl wir hier nahezu völlig von Sx und Sx2 abgedriftet sind und uns wieder einmal mit NMRA-DCC beschäftigen. Auch wenn ich mit den Unschärfen der Fuzzy Logic vertraut bin, so schätze ich unscharfe Aussagen und Annahmen nicht sonderlich. Im Unternehmen ist bekannt, dass ich sie nur dann akzeptiere, wenn keine detaillierten Informationen vorliegen oder zu beschaffen sind.

In Antwort #30 steht – Zitat :
> Natürlich kommen wir rechnerisch auf "dasselbe" Ergebnis. Jeder kann die RP lesen und nachrechnen - ist ja keine Hexerei.

Wer viel und insbesondere häufig schreibt sollte auch viel und aufmerksam lesen. Ich habe dies beherzigt und noch einmal gelesen und zwar in den:
NMRA-DCC Standards and Recommended Practices
S-9.1 DCC Electrical Standard July 2004
S-9.2 DCC Communications Standard July 2004
RP-9.2.1 DCC Extended Packet Format July 2003
RP-9.3.1 DCC Electrical Specifications for Decoder Transmission July 2003
RP-9.3.2 DCC Basic Decoder Transmission July 2003
NEM 670 Digitales Steuersignal DCC – Bitdarstellung
NEM 671 Digitales Steuersignal DCC – Basis-Datenpakete

Und ich muss konstatieren, dass ich mich bezüglich einiger Aussagen, die ich in #23 gemacht habe korrigieren muss. Auch wenn es teilweise nur um Details geht, so möchte ich auch in Anbetracht, dass Ismael einen Artikel über NMRA-DCC verfassen möchte, diese fuzzy mäßigen Unschärfen eliminieren.

Zunächst etwas zu den Bit-Zeiten. Hier zu steht in der S-9.1:
In a "1" bit, the first and last part of a bit shall have the same duration, and that duration shall nominally be 58 microseconds.
Und in der NEM 670:
In einem Einsbit haben der erste und der letzte Teil stets die gleiche Dauer von 58 µs. Die Dauer eines Einsbits beträgt somit 116 µs.
Einigen wir uns also darauf. Eine log. "1" dauert bei NMRA-DCC 116µs.

Bezüglich der Codierung der log. "0" ist dort zu lesen:
In a "0" bit, the duration of the first and last parts of each transition shall nominally be greater than or equal to 100 microseconds.
Und in der NEM 670
In einem Nullbit soll die Dauer des ersten und letzten Teils zwischen zwei Nulldurchgängen (jeweils) größer oder gleich 100 Mikrosekunden sein.
Damit hat entsprechend der Empfehlung eine log. "0" eine zeitliche Länge von 200µs.

Meine Angabe von 220µs war damit, trotz der insbesondere nach oben möglichen großen Toleranzen, nicht korrekt. Ich bin darauf hereingefallen, dass im Band 10 des alba Buches "Modellbahn digital Fahren" von 1990 eine Frequenz für die log. "0" von 4,5kHz angegeben war. Dies entspräche einer Bit-Zeit von 222µs.

Eventuell kann einer der hier vertretenen Experten einmal ein NMRA-DCC Signal unter Angabe der verwendeten Zentrale oszillographieren und Ismael zur Verfügung stellen. In Ermangelung einer NMRA-DCC fähigen Zentrale kann ich dies leider nicht. Ich bin aber gerne bereit ein entsprechendes Oszillogramm eines Sx-Signals beizusteuern.

Nun zur Preamble. Hierzu ist in den oben zitierten Normen zu lesen:
A command station must send a minimum of 14 full preamble bits. (S-9.2)
und
This means that a minimum of 17 preamble bits exclusive of the packet end bit must be transmitted to ensure full compatibility. Transmitting a minimum of 18 preamble bits exclusive of the packet end bit is preferred. (RP-9.3.1)

Das die Aktivität der Dekoder einleitende Signal besteht aus einer Folge von mindestens 14 Einsbits und synchronisiert sie. (NEM 671)

Wieviele Preamble Bits die aktuellen Zentralen tatsächlich senden entzieht sich meiner Kenntnis. Im bereits oben zitierten alba Buch war von 20 die Rede. Wäre schön, wenn die NMRA-DCC Freakes hier eine Info von den einschlägigen Hersteller besorgen könnten. Es interessiert mich schon rein technisch.

Zusammenfassend muss gesagt werden unter 14 Bit geht hier nichts. Woher die hier von anderer Seite gestreuten 12 Bit kommen ist mir unbekannt.

Mit diesen Infos nun erneut ein Blick auf das _kürzeste_ bei NMRA-DCC mögliche Datenpaket. Dies besteht aus: 14 Preamble Bits mit log. "1": 14 * 116µs = 1624µs
3 Start-Bit für die nachfolgenden 3 Bytes: 3 * 200µs = 600µs
16 Daten/CRC-Bits mit log. "1": 16 * 116µs = 1856µs
8 Daten/CRC-Bits mit log "0" 8 * 200µs = 1600µs
Macht zusammen: 5680µs.

Darunter geht nichts. Wobei ich das Packet End Bit auch schon weggelassen habe, da dieses unter bestimmten Umständen zusammenfallen kann mit dem ersten Einsbit der Synchronisationsphase des folgenden Datenpaketes. Wer nun behauptet ich hätte auch die 8 Daten/CRC-Bits, welche ich mit log. "0" betrachtet habe mit log "1" hätte rechnen können beweist, dass er das Prinzip der CRC-Berechnung im NMRA-DCC System nicht kennt.

Ein typisches Datenpaket, wie es z.B. in der NEM 671 für die Adresse 55 in Vorwärtsfahrt mit Fahrstufe 6 graphisch dargestellt ist hat damit im günstigsten Fall eine zeitliche Ausdehnung von: 6ms.

Bei der obigen Betrachtung handelt es sich allerdings um das _kürzeste_ Datentelegramm, welches derzeit bei NMRA-DCC definiert ist. Damit sind max. 28FS und eine Zusatzfunktion möglich! Wird eine lange Adresse mit den hochgeschätzten 128FS genutzt, so wird ein Telegramm gesendet, welches wie bereits gesagt aus der Preamble und 5 Byte besteht. Dessen Übertrag dauert wie in diesem Thread bereits dargelegt über 9ms.

In Nachricht #30 steht –Zitat:
Warum du aber auf 8ms für Funktionen kommst ist mir nicht ganz klar. Ein Fahrbefehl hat das selbe Format wie eine Funktion, dauert also auch genausolange

Die Übertragung der Stati der Zusatzfunktionen erfolgt in einem von den Fahrstufen separierten Datenpaket. Hierfür sind 3 Funktionsgruppen definiert, die jeweils die Information für 4 Zusatzfunktionen aufnehmen können, wobei in der Funktionsgruppe 1 zusätzlich noch die Information für den Lichtausgang transportiert wird. Im aktuellen NMRA-DCC Format können damit 12 Zusatzfunktionen und der Lichtausgang angesprochen werden.

Um für diese 13 binären Signale die notwendige Information zu übertragen, benötigt das NMRA-DCC System drei Datenpaket mit einer Länge von jeweils 4 Byte und nicht 5 Byte wie bei langen Adressen mit 128FS. Jedes dieser aus 4 Byte bestehende Funktionsgruppen-Telegramm benötigt eine Übertragungszeit von knapp 8ms.

Deprimierender Weise muss ich feststellen, dass ich mich in meiner Nachricht #23 geirrt habe. Dort konstatierte ich, dass ein NMRA-DCC System ca. 18ms benötigt um ein Fahrzeug mit langer Adresse, 128FS und 12 Zusatzfunktionen (+Licht) zu versorgen und äußerte mein Unverständnis wieso ESU hierfür ca. 30ms angibt.

Trotz der (beabsichtigten?) Verwirrung die @25 hier mit dem unpassenden Zitat:
It shall be possible to configure Digital Command Stations to transmit at
least one complete packet every 30 milliseconds as measured from the time
between packet start bits 12.13
12 Some DCC decoders manufactured prior to the NMRA standards require a
valid baseline packet be received every 30 milliseconds to prevent analog
power conversion.
13 Longer repetition rates may result in less than optimal decoder
performance

gepaart mit der konfusen Anmerkung: "DCC kanns wenigstens, bei SX ist ja keine Rede davon "
in das Spiel brachte habe ich die Lösung dank Nachlesens nunmehr gefunden.

Wie oben bereits gesagt benötigt ein NMRA-DCC System nicht, wie von mir irrtümlich angenommen ein 4 Byte langes Telegramm für die 12 Zusatzfunktionen + Licht sondern drei. Damit dauert die Übertragung - bei einer positiv angenommenen Länge eines jeden Telegramms von 7ms - der 3 Pakete in Summe 21ms. Fehlt noch das Datenpaket für die 128 Fahrstufen dessen zeitliche Länge ca. 9ms beträgt. Macht in Summe 30ms.

Noch einmal in Kurzform, um ein Fahrzeug mit langen Adressen, 128FS und 12 Zusatzfunktionen + Licht vollständig mit Daten zu versorgen, benötigt ein NMRA-DCC System 4 Datentelegramme, deren Übertragung in Summe ca. 30ms dauert. Bei 10 aktiven Fahrzeugen dieser Art dauert ein Aktualisierungszyklus also schon 300ms und dabei bedeutet aktiv auch schon, dass lediglich das Licht eingeschaltet ist.

Es ist mir schon klar, dass ich jetzt nicht unbedingt 300ms warten muss, wenn ich bei dem 11.ten Fahrzeug das Licht einschaltet, da NMRA-DCC Systeme, wie es hier ja kontinuierlich gepredigt wird geänderte Daten azyklisch bevorzugt übertragen. Was aber ist, wenn dieses bevorzugt übertragene Datenpaket verloren geht?

Es entzieht sich meiner Kenntnis wer und inwieweit sich der ein oder andere hier schon einmal mit Energie-Datenbussen beschäftigt hat und da insbesondere mit solchen, die größere Kontaktunsicherheiten aufweisen und deren Übertragungsmedium (Gleis) durch andere Teilnehmer gestört wird. Bei stehenden Loks ist, Kontakt vorausgesetzt und der Einfluss von anderen Busteilnehmern ausgeschlossen, die Empfangswahrscheinlichkeit nahe 100%.

Bei mehreren schnell fahrenden, beleuchteten Zügen sieht dies allerdings schon anders aus. Abhängig vom System (2 Leiter wie bei N oder mit Mittelleiter) und der Spurweite sinkt nach Aussage von Personen, die sich mit dieser Materie intensiv beschäftigen, die störungsfreie Empfangswahrscheinlichkeit abhängig von der Telegrammlänge (je kürzer je besser) auf unter 50% ab. Dies bedeutet, dass nur noch jeder 2 oder 3 Befehl sauber erkannt wird.

Eine bevorzugte Übertragung geänderter Daten ist damit ein probates Mittel Verzögerungen zu kaschieren, ein Allheilmittel alleine ist es nicht. Hierfür ist zusätzlich eine hohe Wiederholungsrate der Datentelegramme von Nöten. In der NEM 671 steht hierzu – Zitat:
Die zu Dekodern gesendeten Datenpakete sollen so oft wie möglich wiederholt werden, weil sie durch Störungen oder schlechter elektrischer Leitfähigkeit zwischen Schienen, Rädern und Stromabnehmern Informationsverluste erleiden können.

Auch wenn @28 einwirft, dass wir hier über µs diskutieren, so gebe ich zu bedenken, dass es nach der oben dargelegten Erläuterung bei NMRA-DCC System mit 30 aktiven Loks im Sekundenbereich liegen kann, bis eine fahrende Lok eine Geschwindigkeitsänderung annimmt. Es ist für mich schon bemerkenswert, dass NMRA-DCC Anhänger offensichtlich die Datenwiederholungsrate als kein so wesentliches Kriterium betrachten. Oder konnte man mit dem Begriff Refresh Rate den ich ins Spiel brachte nichts anfangen und spielte deshalb das alte Lied ab, dass NMRA-DCC System Ereignis gesteuert übertragen? Schon bemerkenswert, dass kein weiterer Beitrag Bezug genommen hat auf die Datenwiederholungsrate. Ich kann bezüglich der spontanen Ereignisgesteuerten Übertragung nur sagen, auch wenn Sx die Methode derzeit nicht anwendet, weil es wegen der schnellen Aktualisierung auch nicht notwendig ist und es zudem die Programmierung in der Zentrale extrem vereinfacht, so ist dies ein Ass, welches Sx bei Bedarf jederzeit noch aus dem Ärmel ziehen kann und zusammen mit Sx2 womöglich auch tut.

Auch wenn ich die Aussage von @32 nicht uneigeschränkt teile – Zitat:
Ok, wenn ich diesen ganzen Technobabbel richtig verstanden habe, ist es also für Otto Normalbahner mit seiner kleinen Bahn, die für 5 Züge ausgelegt ist, schnurzpiepegal, ob er DCC odr SX fährt.

So kann ich doch ganz gut damit leben. Allerdings gebe ich zu bedenken, dass der schnelle, störungsfreie Datenempfang eines Sx-Signals, wegen der kürzeren Übertragungszeit seiner polaritätscodierten Bits und seiner höheren Datenwiederholungsrate (Refresh Rate), sicher gerade auch bei Spur N ein Vorteil darstellt (BTW:Auch wenn ich jetzt Brügel dafür beziehe, ich fahre HO. Und es liegt mir fern dies zu sagen, um eine weitere Aussage von @33 ad absurdum zu führen. Zudem kenne ich eine Reihe von Personen, die es mir gleich tun.)

Interessant finde ich noch die Bemerkung von @29. Ich zitiere:
Zu der RP 9.3.1 ist leider zu sagen, dass hier erstmals kontraproduktive Kräfte innerhalb der DCC-WG tätig sind. Nicht jeder wünscht sich Bi-Di so, wie es in der RP vorgesehen ist. Allerdings muß auch gesagt sein, daß die Bi-Di in DCC wesentlich umfangreicher ist als mfx heute oder SX2 irgendwann.

Ich habe derzeit keine Info darüber was die Bi-Direktionale Kommunikation bei Sx2 leistet wird und die von NMRA-DCC ist nach meiner Kenntnis für den Endanwender noch nicht verfügbar. Ich kann nur feststellen, dass bei Sx2 dem Lokdecoder ein größeres Zeitfenster zur Verfügung steht Daten zurückzuschreiben als bei NMRA-DCC (ca. 600µs gegenüber ca.450µs). Zudem kann sich sein Energiespeicher durch das intermittierende Verfahren immer wieder aufladen und damit stärkere Stromimpulse liefern als bei NMRA-DCC, wo der Decoder alle 3 Rückmeldebytes in _einer_ Signalpause schreiben muss. Da an Hand der getätigten Äußerungen hier bez. der Fähigkeiten der Bi-Di aber offensichtlich schon weitere Informationen vorliegen, bitte ich höflichst und sicher auch im Interesse der Mitlesenden, uns nicht im Dunkeln stehen zu lassen. Danke.

P.S.: Wenn ich das bei dieser Gelegenheit sagen darf. Das Forum finde ich Klasse und auch für HO´er äußerst interessanter. Im Vergleich zu dem was man an anderer Stelle gelegentlich lesen muss, geht es hier extrem kultiviert zu. Auch wenn die Aussage für mich selbst als HO´er negativ ausfällt, so scheint  es mir doch so als würde sich der Spur-Maßstab umgekehrt proportional zum Intellekt verhalten.

Ich möchte mich bei H.W. für die ausführliche Information bedanken, komme allerdings nicht umhin, auf einen Rechenfehler zu verweisen.

Ein DCC-Standardpaket besteht normgemäß aus 14 Preamble-Bits (116µsx14), 1 0-Bit als Packet-Startbit des ersten Datenbytes (200µs), 8 Bits (statistisch 4x0 + 4x1 = 116µsx4+200µsx4), 1 Databyte-Startbit (0-Bit) als Startbit des zweiten Bytes (200µs) plus wieder einem Datenbyte (4x0 + 4x1, wie vor) sowie einem Stopbit (116µs) sowie einer minimum precedence-Zeit von 26µs. Dies macht in Summe 4,68 ms aus.

Extended Packet Format kann nach RP 9.2.1 zwischen 3 und 6 Datenbytes umfassen, jeweils angeführt von einem 0-Bit (damit wird das Paket um jeweils
1,464ms je Datenbyte länger).

2 Datenbyte 4,68ms
3 Datenbyte 6,14ms
4 Datenbyte 10,61ms
5 Datenbyte 12,07ms
6 Datenbyte 13,54ms

Daher kann ich die apostrophierten 30ms nicht nachvollziehen.


Generell halte ich die höhere Wiederholrate bei SX in Zusammenhang mit kürzeren Paketen für technisch sauberer, da die Fehlerwahrscheinlichkeit mit längerer Paketdauer ansteigt (wobei ich mir ohne Recherche nicht sicher bin, ob die Fehlerwahrscheinlichkeit linear oder nicht gar exponentiell verläuft - ich habe dazu noch zu wenig Unterlagen gefunden). Allerdings bedingen kürzere Datenpakete höheren Overhead, womit Vorteile wiederum vermindert werden.

Ich bin beileibe nicht für einen Glaubenskrieg zu haben - meiner Meinung aus dem "Bauch" heraus halte ich SX für das unkompliziertere System, DCC für das (im Augenblick) leistungsfähigere, auch wenn beide Systeme mit einigen (konzeptionellen) Nachteilen behaftet sind. Aber da gehts uns wie mit der Abwärtskompatibilität mit den PCs...

Vielleicht zum Schluss noch erwähnt - ich fahre derzeit analog mit Pulsweitenmodulation.

LG

Enrico

@Enrico
Du hast in deiner Berechnung das Ø-bit vor dem CRC-Byte vergessen.
Wie verhält sich eigentlich das XOR-CRC byte bei streng statistische Verteilung von byte 1 und 2 ?
Bezüglich des genannten Beispieltelegrammes aus NEM 671 ergibt sich eine Zeitdauer von 5,92 ms inkl. Stoppbit und precedence.

Zastrow

Danke für die Korrektur.
Ich hab eigentlich nur ein statistisches "Durchschnittspaket" gemeint - daher müssten dann etwa gleich viel 0 wie 1 beim CRC herauskommen oder als Bitzeit (0-Zeit+1-Zeit)/2

LG

Enrico

@31 - übrigens, die Fortpflanzungsgeschwindigkeit der Impulse auf den Schienen ist etwa 240 bis 270 m/µs ... so groß kann die ganze Anlage nicht sein, dass dies eine Rolle spielen könnte
Diese Fortpflanzungsgeschwindigkeit ist nur von der Längsinduktivität der Schienen und der Kapazität zwischen den Schienen abhängig. Ich habe interessehalber 5 Peco Flexgleise zusammengesteckt und mit einem Reflektometer mit 0,1 ns Pulsbreite gemessen - als HF-Leiter sind die Peco nicht schlecht

Enrico

*g*, dann steht dem Ganzen ja nichts im Wege, dass wir bei DCC die Pulsdauern um den Faktor 1000 verkürzen. Zumindest bis das gelbe Auto mit dem Geweih am Dach vor der Tür steht.

Zastrow

Wird nur interessant, was der Rad-Schiene-Kontakt und dann die Rad-Stromabnahme zu HF sagt. Aber bis zu etwa 10µs Impulsdauer sollte die Sache schon funktionieren - und da störst höchstens die Zeitzeichensender

Interessanter ist schon eher, wie die Impulsverformung dann aussieht und ob die Dekoder dann noch einwandfrei entziffern können.

Enrico

>> Apropos Claus: Habt ihr Santa oder das Christkind auf Saipan? <<

Wir haben beides: 25.12. bringt Santa Geschenke (jede Menge Gleise, und ne neue Camera), am 6.1. kommt das Christkind und bettelt für die Kirche ....

zurück zum Studio,
Claus

Hallo Enrico, hallo Digitalos,

in der unter #35 vorgelegten Rechnung fehlt leider nicht nur wie von @Zastrow richtig erkannt das log. "0" Start-Bit für das CRC-Byte, sondern auch das CRC-Byte selbst. Dieses schlägt auch noch einmal mit 1,26ms (4* 116µs + 4 * 200µs) zu buche. Es bleibt nun einmal dabei, dass das kürzeste Datenpaket, welches derzeit bei NMRA-DCC definiert ist aus 2 Nutzbytes und dem unvermeidlichen CRC-Byte besteht und damit landen wir zusammen mit der Preamble und den Startbits wieder bei ca. 6ms.

Die weitere Auflistung der Paketzeiten ab 3 Byte findet meinen Einklang.

Die von ESU genannten und mittlerweile auch von mir verstandenen 30ms ergeben sich aus dem Sachverhalt, dass NMRA-DCC in Summe _vier_ einzelne, zeitlich nicht unmittelbar aufeinander folgende Datenpaket senden muss, um ein Fahrzeug, welches lange Adressen und 12 Zusatzfunktionen + Licht nutzt, vollständig mit Daten zu versorgen.

In diesen 4 zeitlich separierten Datenpaket ist folgende Information enthalten:
Packet A: Übermittlung von Fahrtrichtung und FS: 5 Byte, Dauer ca. 9ms
Packet B:Übermittlung der Stati von Zusatzfunktion 1 .. 4 plus Licht: 4 Byte, Dauer ca. 7ms
Packet C:Übermittlung der Stati von Zusatzfunktion 5 .. 8: 4 Byte, Dauer ca. 7ms
Packet D:Übermittlung der Stati von Zusatzfunktion 9 .. 12: 4 Byte, Dauer ca. 7ms

Macht in Summe 9ms + 7ms + 7ms + 7ms = 30ms. Es wird also nicht, wie eventuell vermutet 1 Datenpaket mit einer zeitlichen Dauer von 30ms gesendet, sondern _vier_ einzelne mit einer Gesamtdauer von 30ms. Die Aufteilung der Daten in 4 einzelne Paket hat den Vorteil, dass diese Pakete natürlich kürzer sind als ein Gesamtpaket und damit weniger anfällig gegen Übertragungsfehler. Es hat aber gleichzeitig den Nachteil, das der Overhead größer wird und damit auch die Übertragungszeit in Relation zu einem Einzelpaket ansteigt.

Bei den NMRA-DCC Datenpaketen ist zudem zusätzlich zu berücksichtigen, dass der zeitliche Abstand zweier Datenpaket an den selben Adressaten mindestens 5ms betragen muss.

In der NEM 671 steht hierzu unter: 5.1. Zeitabstand zwischen 2 Datenpaketen – Zitat
> ... Dekoder müssen einsatzbereit (empfangsbereit) sein, wenn die an sie adressierten Datenpakete mehrfach mit einem Zeitabstand von mindestens 5 Millisekunden zwischen dem Stopbit des ersten Paketes und dem Startbit des zweiten Paketes empfangen wurden.<

Streng genommen kommen also noch einmal 4 Zwischenpaket mit einer minimalen Dauer von je 5ms dazu, bis der Zyklus wieder von vorne beginnt. Ist nur ein Fahrzeug aktiv, so wird zwischen den einzelnen Datenpaketen ein Idle-Signal eingeschoben, sind mehrere Fahrzeuge aktiv, so werden die Daten dieser Adressaten verschachtelt übertragen.

Machen wir es aber nicht zu kompliziert, sondern reduzieren wir das Ganze auf eine weiter oben von mir getroffene und nunmehr hoffentlich auch belegten Kernaussage. Um die Information für eine Adresse aus dem Bereich 1 .. 10 000 unter Verwendung von 128FS und 12 Zusatzfunktionen plus Licht zu übertragen, benötigt ein NMRA-DCC System in Summe _vier_ Datenpaket die total ca. 30ms Übertragungszeit beanspruchen.

Sx2 wird die gleiche Information in einem Datenpaket übertragen und dafür lediglich 3,2ms ([4 Sync.-Bit + 40 Daten-Bit + 20 Check-Bit] * 50µs/Bit = 64 Bit * 50µs/Bit = 3,2ms) benötigen. Die störungsfreie Empfangswahrscheinlichkeit eines solchen Datenpakets dürfte, auf Grund der polaritätsbehafteten Bit-Codierung und der in Relation zu einem NMRA-DCC Paket zudem deutlich kürzeren Übertragungszeit, damit wesentlich höher liegen. Soviel zur Aussage, dass kürzere Datenpaket zwangsläufig mehr Overhead hervorrufen.

@W.H

Eine Frage hätte ich noch: Arbeiten SX Decoder mit ECC oder so wie die DCC-Decoder mit EDC ?

Zastrow

@alle Also ich hab keine Fragen mehr.
Bzw. doch eine Frage habe ich doch noch:
Darf ich eigentlich mit meinem "Nichtwissen" überhaupt eine Modellbahnanlage anschauen?? Fahren lassen traue ich mich jetzt eh nicht mehr.
Bis jetzt war meine Auffassung: Wenn es fährt dann gut, wenn es nicht fährt dann nicht gut. Punkt, fertig.  

Nachdenkliche Grüße
ust

@ ust:

Na ja - eigentlich sollte man schon wissen was man tut... )))))

Auch wenn der Thread jetzt sehr technisch war, muss ich sagen, dass es sicher noch nicht viele Diskussionen mit dieser Qualität gibt.

lg
ismael

Noch einmal ein hallo an alle Digitalos,

in #43 fragt Zastrow:
> Eine Frage hätte ich noch: Arbeiten SX Decoder mit ECC oder so wie die DCC-Decoder mit EDC ? <

Sx-Decoder wenden das EDC-Verfahren (EDC – Error Detection Code, ECC – Error Correction Code) an. Die aktuellen Decoder plausibilisieren dazu, ob nach dem Sync-Zeichen, welches aus der Sequenz 0001 besteht jedes 3 Bit eine log. „1“ aufweist und ob die Anzahl der Bits eines Frames (von Sync-Zeichen zu Sync-Zeichen) 96 Bit beträgt. Nur unter diesen Voraussetzungen nehmen Sie ein an sie adressiertes Datenpaket entgegen.

Einen Forderung nach einem minimalen zeitlichen Abstand zwischen 2 an den selben Adressaten gerichteten Datenpaket existiert bei Sx nicht. Prinzipiell könnten damit bei Sx Daten kontinuierlich nur an einen Adressaten gesendet werden und dieser würde die, wenn keine Übertragungsstörungen auftreten, auch akzeptieren.

Damit hier keine Verwechslung entsteht. Das gerade gesagte gilt für das aktuelle Sx-Protokoll. Bei der Protokoll-Erweiterung in Richtung Sx2 gibt es nur insofern einen Unterschied, als hier die Plausibilisierung eines Sx2-Datenpakets nicht auf eine Telegramm-Länge von 96 Bit angewendet werden wird, sondern auf eine von 64 Bit oder 68 Bit je nachdem ob man sich entscheidet, ein Sx2-Packet mit einem oder 2 Sync-Zeichen einzuleiten. Wenn die mich fragen würden, so gäbe ich die Empfehlung 2 Sync-Zeichen zu verwenden. Weniger wegen der Funktionalität am Gleis sondern mehr wegen der Busverwaltung am synchron laufenden Sx-Bus. Ob die Paketlänge nun 3,2ms beträgt oder 3,4 spielt nach der hier ausführlich geführten Diskussion und den hoffentlich gewonnenen Erkenntnissen sicher keine gravierende Rolle.

Besten Dank, allerdings ist dann anzumerken, dass die getätigte Aussage aus #23
**
sein Protokoll und die wenig überzeugende Hamming-Distanz von 2 seines CRC-Checks ringen mir allerdings keinen großen Respekt ab.
**
zu revidieren ist, denn, auch wenn SX mit einer Hamingdistanz d=4 arbeiten würde, es keinen zusätzlichen Nutzen bringt. Kurz gesagt: Ein bit hin, gesamtes Telegramm Schrott. So gesehen spielen beide Systeme - solange kein Software-Handshake da ist - Star Wars : Wir schiessen so lange in den Himmel bis wir treffen oder die Munition ausgeht.

Nachdem ich bis jetzt "Salto Mortale ohne Netz" geschrieben habe, nun zu #42:
Ich habe RP 9.2.1 aus dem Papierkorb gezerrt und merke an: Zu Beginn wird festgestellt , das ein Extended erstmal aus dem Standard-Telegramm (3 byte) besteht, wahlweise jedoch auf bis zu 6 byte ausgedehnt darf, jeweils getrennt durch eine Ø. Wenn jetzt ESU meint, die "extended" Daten byteweise  einzeln zu übertragen, ändert dies nichts an der Tatsache, dass jimmer das Standardtelegramm (mit  den letztgültigen Werten) mitgesandt werden muss. Wie viele ms das jetzt ergibt, mag ich nimmer ausrechnen.
Viele Wege führen nach Rom, ESU hat den (theoretisch) längsten gewählt.
Allerding gestehe ich zu, das die Decodierung des (nach extendedNMRA-Signales erzeugten) CRC im Decoder schon zu zeitaufwändigen Routinen führen kann. Die Zentrale mit entsprechend leistungsfähigen Prozessoren hat bei der Codierung Byte1 XOR Byte2 = Zwischenergebnis XOR Byte3 = Zwischenergebnis....etc. kein Problem, im Decoder wird es eng.

m2c

Zastrow

Hallo Zatrow/Zastrow und sonstige Digitalos,

W. H. schrieb in #23 bezogen auf NMRA-DCC – Zitat:
> Sein Bit-Codierungsschema, sein Protokoll und die wenig überzeugende Hamming-Distanz von 2 seines CRC-Checks ringen mir allerdings keinen großen Respekt ab. <

Zatrow schreibt in Bezug darauf und in Bezug auf Antwort #46 in #47 – Zitat:
> zu revidieren ist, denn, auch wenn SX mit einer Hamingdistanz d=4 arbeiten würde, es keinen zusätzlichen Nutzen bringt. Kurz gesagt: Ein bit hin, gesamtes Telegramm Schrott. <

Ich muss meine oben zitierte Aussage aus #23 etwas konkretisieren. Seine Hamming-Distanz von 2, ist bezogen auf den Nutzdateninhalt eines Paketes (bei langen Adressen und 128FS z.B. 4 Byte, das Gesamtpaket incl. CRC-Check besteht dann aus 5 Byte) nicht besonders imposant und ringt mir damit keinen großen Respekt ab.

Die Angabe der Hamming-Distanz alleine sagt über die Qualität der Fehlererkennung noch nichts wesentliches aus. Sie beschreibt zunächst nur wie viele Bits falsch eingelesen werden können, damit dies im Empfänger mittels Auswertung des ebenfalls empfangenen CRC-Checks (und auch dieser kann fehlerhaft empfangen worden sein) mit 100%-iger Sicherheit erkannt wird.

Bei einer Hammining-Distanz von 2 kann nach der Formal h - 1 (bei NMRA-DCC gilt h = 2) _ein_ fehlerhaft gelesenes Bit mit 100%-iger Sicherheit erkannt werden. Dies bedeutet, dass der Empfänger (Lok-Decoder) in einem NMRA-DCC System innerhalb eines 5 Byte langen Telegramms (= 40Bit) _ein_ fehlerhaft empfangenes Bit mit 100%-iger Wahrscheinlichkeit erkennt. Zwei auf Grund von Übertragungsstörungen falsch erkannte Bits können nicht mehr mit 100%-iger Sicherheit erkannt werden. Allerdings kann man auch nicht sagen, dass diese nie erkannt werden. Es kommt darauf an, wo die beiden falsch erkannten Bits im Datenstrom liegen.

Bei der bei NMRA-DCC angewanden EXOR-Verknüpfung zur Berechnung des CRC-Checks müssen die falsch erkannten Bits in separaten Bytes liegen (z.B. in Byte 1 und Byte 2 oder Byte 2 und Byte 5, etc.) und dort dieselbe Bit-Position z.B. Bit 5 annehmen, um nicht als Übertragungsfehler erkannt zu werden.

Die Wahrscheinlichkeit, dass bei einem Übertragungsfehler das falsch erkannte Bit an einer bestimmten Position innerhalb eines Bytes liegt ist 1/8 (da wie bekannt ein Byte 8 Bit beinhaltet). Geht man davon aus, dass die in den einzelnen Bytes fehlerhaft erkannten Bits statistisch unabhängig voneinander sind, so ist die Wahrscheinlichkeit, dass fehlerhafte Bits in 2 separaten Bytes an der gleichen Position liegen 1/8 * 1/8 = 1/256. Konkret gesagt bedeutet dies, dass wenn innerhalb eines Datenpakets von z.B. 5 Byte Länge in 2 separaten Bytes je ein Bit falsch eingelesen wird, so wird dies mit einer Wahrscheinlichkeit von 1/256 nicht erkannt! Oder kürzer gesagt jeder 256 Fehler dieser Art wird nicht erkannt und dies ist bezogen auf die Telegrammlänge kein berauschender Wert.

Gerechter Weise muss ich allerdings sagen, dass das bei NMRA-DCC angewendete Verfahren zur Erkennung von Übertragungsfehlern jede ungerade Anzahl fehlerhaft erkannter Bits erkennt. Zudem werden gute Lokdecoder auch mit Verzögerung auf ein z.B. falsch erkanntes Fahrtrichtungsbit regieren – alles andere wäre fatal – und sie sollten auch eine sprunghafte Fahrstufenänderung nicht direkt annehmen. Im allgemeinen tun sie dies ja auch nicht, weil Fahrstufenänderungen über die decoderinternen Rampen erfolgen. Insbesondere, wenn man LED´s verwendet soll man angeblich allerdings falsch ausgewertete Daten-Bits gut an deren unmotiviertem Aufblitzenden erkennen.

Ohne hier eine mathematische Abhandlung über die Erkennung von Übertragungsfehlern bei Sx zu liefern, hier noch einmal der Hinweis das dort jeweils 2 Bit mit einem Sicherungsbit gepaart werden. Die Wahrscheinlichkeit der Erkennung von Kommunikationsfehlern ist damit unabhängig von der Paketlänge.

Noch etwas zu der Hamming-Distanz wie in #47 richtig erwähnt muss diese mindestens einen Wert von 4 aufweisen, damit eine Fehlerkorrektur möglich ist. Wie bekannt gilt für die Anzahl korrigierbarer Bits: k = (h-1)/2.

Sx hat auch keine Hamming-Distanz von 4. Bezogen auf die jeweils mit einem Check-Bit gepaarten 2 Daten-Bits ist dies auch nicht verwunderlich. Allerdings verfügt Sx damit nicht nur über ein besseres Verfahren zur Erkennung von Datenübertragungsfehlern, sondern es kann es sich aufgrund seiner hohen Refresh Rate (Datenwiederholungsrate) auch leisten, einige fehlerhaft erkannte Datenwort zu überlesen. Diese kommen ja spätestens nach 80ms (exakt 76,8ms) immer wieder vorbei.

Zu der Aussage in #47 – Zitat
> ... Standard-Telegramm (3 byte) besteht, wahlweise jedoch auf bis zu 6 byte ausgedehnt darf, jeweils getrennt durch eine Ø. Wenn jetzt ESU meint, die "extended" Daten byteweise einzeln zu übertragen, ändert dies nichts an der Tatsache, dass immer das Standardtelegramm (mit den letztgültigen Werten) mitgesandt werden muss. <

ESU, unter anderem auch Anbieter NMRA-DCC kompatibler Decoder, meint nicht, dass „extended“ Daten byteweise einzeln zu übertragen sind, sondern der Sinn einer Protokolldefinition und Normung liegt darin, dass sich alle daran halten. Dies bedeutet, dass ESU dies nicht anders sehen kann als ZIMO, Tran, Lenz, Uhlenbrock, Digitrax oder sonst wer. Wie was zu übertragen ist, ist in der Norm klar festgelegt und wurde in den von mir aufgeführten Beispielen auch entsprechend berücksichtigt und integriert.

Eine kleine Empfehlung für alle Interessierten, in der Miba Ausgabe 1 „Modellbahn digital“ von 2001 sind auch die bis dato definierten NMRA-DCC Telegramme beschrieben und durch graphische Darstellungen veranschaulicht. Diese Ausgabe liegt als pdf-file auf der Heft CD vor, die dem aktuellen Miba Digital Heft mit dem Titel <MIBA extra - Modellbahn digital 5> beiliegt. Dort ist die Datei zu finden unter DokumentationEXTRAdig1.pdf.

So jetzt habe ich hier aber genug mitdiskutiert. Eventuell hat es ja dem ein oder anderem geholfen, sein Digital-System besser zu verstehen. Wäre schön, wenn nicht auch nicht so dramatisch. Meine Blonde weiß auch nicht wie der Motor in ihrem Auto funktioniert und ich muss zugeben für die Steuer- und Regelsystem interessiert sie sich noch weniger. Sie fährt einfach und gut. Für Grundlagenforschung und Radwechsel gibt’s andere.

Lieber W.H.(obwohl ich immer noch nicht weiß wer du bist

Die NEM wie auch immer kannst du getrost vergessen. Danach richtet sich sicher niemand in der DCC-WG. Und es ist auch sicher keine Norm im ursprünglichen Sinn. Vor allem die aus 2001 stammenden NEM 670 und 671 sind ja nur abgeschreibsel der S9

Ich mußte mir diesen Wust in Nr 34 ausdrucken. So viel hat ja noch niemand zu DCC geschrieben. Es waren in Word 4 Seiten.

Nun einige Bemerkungen zu deinen bemühten, aber leider nicht ganz korrekten Bemerkungen.

"Zunächst etwas zu den Bit-Zeiten. Hier zu steht in der S-9.1:
In a "1" bit, the first and last part of a bit shall have the same duration, and that duration shall nominally be 58 microseconds.
Und in der NEM 670:
In einem Einsbit haben der erste und der letzte Teil stets die gleiche Dauer von 58 µs. Die Dauer eines Einsbits beträgt somit 116 µs.
Einigen wir uns also darauf. Eine log. "1" dauert bei NMRA-DCC 116µs."

Das ist, liest man die S9.1 korrekt, falsch.
Es handelt sich hier um ein Zeitfenster, welches je nach Zustand der impulserzeugenden Einheit, dem Load, ect. unterschiedlich lang sein darf. Nominal ist eben nicht real.

Auch werden hier zwei Fakten vermischt. Handelt es sich um die Zentrale, den Decoder oder der Kombination aus beiden.  

Lesen wir also die Standards und RP´s mal richtig:
Im Standard 9.1:

One Bit Timing:..........
For Power Station Output under Load:..........
Decoders must accept:................

Da handelt es sich ja offensichtlich schon um verschiedene Ansätze

In Standard 9.2
........A digital decoder must not accept as a valid,any preamble that has less then 10 complete one bits, or require for proper reception of a packet with more than 12 complete one bits. A command station must send a minimum of 14 full preamble bits..........

soweit sogut. wer aber dann weiterliest merkt:

Speed and Direction Packet For Locomotive Decoders:

111111111111 0 0AAAAAAA 0 01DCSSSS 0 EEEEEEEE 1
Preamble           Byte One       Byte Two        Byte Three (Error Detection Data Byte)

oder

Digital Decoder Reset Packet For All Decoders:

111111111111   000000000 0   00000000 0    00000000 1
Preamble          Byte One        Byte Two       Byte Three (Error Detection Data Byte)

Aaaaaaaaaaaaah! Nur 12 Präamble Bits!

Ich kann also über 10, 12 oder 14 Bits philosophieren so lange ich will, wichtig ist nur, wieviele Bits ein Decoder braucht, um arbeiten zu können und das sind 12.

Warum nun: Weil man von einer Zentrale nicht erwarten kann, daß immer alle Bits durchkommen. So fand man als Lösung einen "Übergang". Wenn jemand zur "Sicherheit" 20 Präambelbits senden will so sei ihm das unbenommen. Wie überhaupt bei DCC jeder die S´s und RP´s auslegt, wie es ihm gefällt. Bei einer genauen Kontrolle aller Zentralen und Decoder bin ich sicher, daß gut die Hälfte nicht DCC-Konform sind. ESU baut eben sehr robuste Geräte, weil so von den OEM´s verlangt. Andere bauen eben technisch aufwendige Geräte, die mehr Inelligenz beinhalten und so effizientere Übertragungen erlauben.

Um nun wieder zu SX zurückzukommen:
SX hat sich Konventionen gebeugt. Dadurch ist es möglich, einfacher zu arbeiten. Eine dieser Konventionen sind die Fahrstufen, eine andere die schwache Funktionalität wie zB die funktionelle Koppelung des Lichts an den Motorregler.

Was mir leider immer wieder auffällt, sind "Kunstgriffe", um DCC langsamer zu machen.  Wenn man DCC und SX schon vergleichen muß, sollte man bei DCC mit 28 Fahrstufen und kurzen Adressen rechnen. Software wie zB Railware empfiehlt sogar außdrücklich mit 28 Fahrstufen zu arbeiten.
Selbst bei SX2 - sollte es das jemals geben - stehen max. 112+64 Adressen bereit. Und auch bei Decodern wird man die alten SX Konventionen übernehmen müssen. Und ebenfalls sollte man sehen, daß die Funktionalität eben seinen Preis in Form von Daten hat. Und da muß man sicher nicht mit 12 Funktionen übertreiben. Wie auch am Markt kaum DCC-Decoder mit mehr als 4 Funktionen verbreitet sind.

Ich möchte mich eigentlich auch nicht weiter über SX2 verbreiten. Sollte es das mal wirklich geben, kann man es sich ansehen. Jetzt ist es noch - anders als Bi-Directional Communication, daß ja funktionell bereits seit 2 Jahren existiert und von Lenz und ZIMO bereits in den Decodern vorgesehen ist - ein ungelegtes Ei. Ob dieses Ei braun oder weiß, groß oder klein ist und ob darin ein Krokodil oder eine Schildkröte heranwächst kann heute niemand sagen, auch wenn ein stolzer Hahn das Ei auszubrüten versucht.

Soweit sogut.
LG, Herkules

PS. Kleiner Nachsatz zu 34.
Am nördlichen Sternhimmel steht Hercules. Und zwar am Haupt des Drachens (Draco)
Schön ist auch M13 (M 13, NGC 6205 Great Hercules Cluster) in ihm. Interessant erscheint auch, daß das Sternbild zu meinem Geburtstag kulminiert.

Aber auch auf den Gleisen ist es Hercules. Oder in den Mythen. Und wenn schon mit "K" dann Herakles.

@H.W., Zastrow und Herkules,

endlich einmal eine fundierte Diskussion die in die Tiefen der unterschiedlichen Digitalsysteme geht. Respekt!

Danke für diese Ausführlichkeit und die Zeit, die Ihr euch nehmt - auch wenn es manchmal für den unbedarften Mitleser etwas zu sehr ins Detail ging. Trotzdem, bitte weiter solche faktisch emotionsfreien Beiträge!

So etwas bringt mir als Digitalbahner und natürlich diesem Forum mehr als irgendwelche Sprüche von sogenannten Ich-weiß-alles-besser-Möchtegern-Spezialisten ohne entsprechendes Fachwissen geschweige denn Praxishintergrund.

Aber da hat ja #13 schon was zu gesagt

Alex

Hallo,

eigentlich wollte ich hierzu nicht schreiben, da sich diese SX DCC Diskusionen ja wiederholen - auch wenn hier sehr schön Hintergrundinfos geliefert werden.

Diesem Informationen nach ist die SX Datenübertragung wohl die bessere.

Anderseits zeigt für mich die Praxis, dass die bessere Datenübertragung nur wenig Einfluss haben kann (ich habe bisher noch nichts Gegenteiliges beobachten können):  
Einher mit einer (stärker) gestörter Datenübertragung geht nämlich auch eine unterbrochene Stromversorgung für den Motor, so dass die Lok nicht mehr ruhig läuft und nicht mehr langsam fahren/kriechen kann...  -> schlechte/verdreckte  Stromabnahme !
Das eine DCC Lok auf verdreckten Schienen unkontrollierbar ist, und einfach weiterfährt - habe ich so noch nicht festgestellt - sie fährt einfach schlecht, weil dem Motor der Strom fehlt.... und eine bessere Datenübertragung verhilft da auch nicht zu mehr Strom.

Selbst eine 100 mal schnellere Datenübertragung als Sx sie bietet, würde nicht helfen die Fahreigenschaften der Lok merklich zu verbessern. Es Verhält sich hier ähnlich wie bei den Fahrstufen: 1000 Fahrstufen machen das Fahren auch nicht merklich besser....

Ist also die Stromversorgung für den Motor hinreichend gut, ist auch eine "schlechte" Datenübertragung via DCC sicher genug....

Für den Anwedender wird daher mehr interessant sein, welchen Funktionsumfang die Systeme bieten und Bedienbarkeit, Kosten und Verfügbarkeit, Service....
Und da haben beide Systeme  Stärken und Schwächen

Auch ich werde mich jetzt aus der Diskussion ausklinken, möchte jedoch noch ein paar Kleinigkeiten aus meiner Sicht darlegen:

Die Diskussion um die Hamingdistanz hat uns nicht viel weiter gebracht. Solange nämlich kein ECC (Fehlerkorrekturcode), der Fehler erkennen und den jeweiligen defekten Teil des Telegrammes im Decoder wieder richtigstellen kann, implemenriert ist, schenken sich die beiden Systeme nichts. Für beide gilt auf Grund von EDC: Ist ein bit im Telegramm falsch, wird das ganze Telegramm vom Decoder verworfen und für ihn beginnt die Zeit des erneuten Wartens auf ein Richtiges.

Zitat Herkules #49:

@51: Hallo Jens
Habe gerade das in Verbindung mit einem Kuehn N025 Decoder und einer verschmutzten GFN 7077 gemacht, bei der Vorlauf und Nachlauf keinen Kontakt hatten. Ansonsten stimme ich der Aussage wozu braucht man 128 Fahrstufen zu. Betrachtet man einen herkömmlichen analogen Transformator, so kommt der mit weniger als 28 Fahrstufen. Dank Anfahrts und Bremsverzögerung sind die einzelnen Stufenübergänge fließend.

Gruß Dirk

Ich kann also über 10, 12 oder 14 Bits philosophieren so lange ich will, wichtig ist nur, wieviele Bits ein Decoder braucht, um arbeiten zu können und das sind 12.

Das will und kann ich nicht unwidersprochen lassen. Die Zentrale sendet nach Norm mind. 14 preamblebits. Schön wenn der Decoder das preamble schon nach dem 12. empfangenen Bit als gültig klassifiziert hat, aber was tut er dann ?
Aaaaaaaaaaaaah!  , da kommt ja noch was und er muss den Empfang zur Kenntnis nehmen und warten, obwohl er zu diesem Zeitpunkt noch nicht einmal weiss, ob er selbst mit dem nachfolgenden Adressbyte gemeint ist.
So ist eine Timingverkürzung sicherlich nicht herbeizudiskutieren. Obendrein: Wenn ich jetzt ganz böse bin, kann ich behaupten: Der Decoder muss im worst-case ein Zeitfenster von 128µs/bit zur Verfügung stellen, d.h. die Übertragung des preambles darf bis zu  1536µs dauern um vom Decoder noch als gültig angenommen zu werden.

Ich selbst fahre DCC (Digitrax) und bin mit dem System für meine Anlagerngrösse zufrieden. Ich stehe jedoch nicht an, allen jenen, die sich mit der ganzen Materie nicht auseinandersetzen wollen oder können und keine imho unnötigen Spielereien brauchen, ein SX - System als konsistente Einheit mit hervorragendem Support zu empfehlen. Wenn ich mir den thread "digit. und analog schalten" durchlese so gehe ich mit der Antwort von Peter W. konform und setzte noch hinzu: Aber mit welchem Aufwand?
Leider ist die Zukunft von SX ungewiss, es wäre schade, wenn es vom Markt verschwinden würde aber vielleicht erlebt es ja schlussendlich eine glanzvolle Wiedergeburt in mfx.

angenehme Feiertage / Jahreswechsel wünscht
Zastrow

Nachtrag, nachdem es in der Mittagspause langweilig war:
So oder ähnlich könnte die DCC-Datenkommunikation aussehen
http://img98.exs.cx/img98/5589/dcc3dg.gif
Übertragungsfehler sind rot markiert.

afk
Zastrow

@Zastow

Du hast vollkommen Recht - die Präambelbits sind eine historisch gewachsene Sache und eigentlich so vollig unnötig. Es trennt nur einzelne Entwicklungsstufen von Digitalsystemen - sozusagen das DCC Erkennungssignal.
Leider wird die Sache nur noch schlimmer, da man diese Präambelbits jetzt für Bi-Di nutzt - und daher kommen auch schlußendlich die 12 Bits.

"This power interruption should not occur unless the power cutout device can reasonably expect that the command station will transmit a minimum of 12 preamble bits to complete the preamble after the completion of the inter packet transmission cutout."

Bi-Di macht also die Übertragung extrem langsam. Und wie auch schon gesagt ist DCC leider 20 Jahre alt und damals waren die Ansprüche eben andere. Heute wird, ähnlich wie beim PC versucht, ewig kompatibel zu bleiben, was bei DCC auch funktioniert - auf Kosten der Geschwindigkeit - wie beim PC.

So ähnlich wie oben beschrieben sieht es nicht nur bei DCC aus sondern bei jeder Datenübertragung. Und trotzdem fahren Züge auf Anlagen, schalten ihr Licht ein und aus und verunglücken recht selten.

mfx kann hier vielleicht einiges mehr, da man auf  einiges Altes verzichten konnte und dafür die Neuheiten und Ideen aus anderen Systemen implementiert hat. mfx hat m.M. so ziemlich des Pudels Kern getroffen und darauf können Märklin und ESU stolz sein. Ob deshalb SX2 kommt oder auch nicht, ist belanglos. Weil wiedereinmal die Masse der Modellbahner in Europa mfx kaufen werden - über die nächsten 20 Jahre besehen. Vielleicht ist dann N ein Nischenmark mit nur 1% Anteil, vielleicht ist DCC dann nur noch bei US-Firmen erhältlich oder mfx floppt und in 20 Jahren hat jeder DCC, daß dann zwar ob seiner 100.sten Weiterentwicklung wirklich nur noch 10 Decoder/sek bedienen kann aber dafür der Decoder auch Radio spielt.

Abschließend möchte auch ich sagen, daß diese Diskussionsrunde wirklich angenehm und fachlich vom Feinsten war. Es würde mich freuen, öfters so sachlich fundierte Diskussionen zu führen.
Auf das uns Zastrow, W.H. nicht nur als Gäste erhalten bleiben.

LG, Herkules